1. Technical Field
The present invention relates in general to a method and system for data processing and in particular to an improved method and system for accessing system resources within a multitasking data processing system. Still more particularly, the present invention relates to a method and system for accessing system resources within a multitasking data processing system which implements a multithreaded operating system kernel that supports kernel-only threads within user processes.
2. Description of the Related Art
A number of currently available multitasking operating systems such as AIX (Advanced Interactive Executive) enable multiple application programs to concurrently execute and share system resources within a data processing system. Typically, each application program comprises one or more processes, which are entities allocated system resources by the operating system. The operating system itself includes a lowest layer, called a kernel, which interacts with the data processing system""s hardware. Like application programs, the kernel comprises multiple processes, which synchronize various system activities, implement multiprocessing capabilities, dispatch process threads, and provide interrupt handling services to device drivers.
Referring now to FIG. 4, there is depicted a conceptual diagram of conventional user and kernel processes within a data processing system. As illustrated, a multitasking data processing system concurrently executes multiple user processes 100, which are each allocated a distinct user address space as well as ownership of other system resources. Each user process 100 comprises one or more user threads 102. As will be understood by those skilled in the art, user threads 102 are abstract entities within the portable programming model for which an application designer writes code. Each user thread 102 is mapped to one or more kernel threads 104 in an implementation dependent manner.
Kernel threads 104 are schedulable entities that execute program steps and consume system resources owned by the processes which include kernel threads 104. Each kernel thread 104 has an associated machine state that consists of the processor register contents, program counter, and other privileged information required to execute kernel thread 104. Multiple kernel threads 104 can execute simultaneously when multiple CPUs are available. When only a single CPU is available, the operating system allocates CPU time slices to each of kernel threads 104 to create an appearance of concurrent execution.
As described above, the operating system kernel includes multiple concurrent kernel processes 106. Each kernel process 106 represents a registered segment of code available to support a function of the data-processing system. For example, the operating system of a data processing system typically includes a number device drivers utilized to manage devices coupled to the system bus of the data processing system. Each of kernel processes 106 can be utilized by the operating system to provide services, such as interrupt handling, for these device driver routines. As illustrated, kernel threads 107, which form kernel processes 106, execute only within a kernel mode environment. Both kernel process kernel threads 107 and user process kernel threads 104 can reference the globally accessible kernel data structures utilized to control operation of the data processing system and to define system resources allocated to each user process 100.
While a kernel thread 104 running under a user process 100 is executing application instructions, kernel thread 104 operates within a user mode environment. However, during its stream of execution, a kernel thread 104 may require access to system resources, for example, to perform a disk read or other asynchronous I/O, which are accessible only from the kernel mode environment. To access these system resources, kernel thread 104 first describes the desired I/O operation utilizing a control block data structure within the user address space assigned to user process 100. In addition, kernel thread 104 specifies whether a notification signal should be issued to kernel thread 104 when the requested data is available. Kernel thread 104 then makes a system call to change domains from the user mode to the kernel mode environment.
Within the kernel mode environment, kernel thread 104 makes a kernel service call to the kernel address space, as illustrated by arrow 108, requesting that a kernel thread 107 running under a kernel process 106 perform the access to the system resources. The kernel service call entails allocating a control block within the kernel address space, filling out the control block, and inserting the control block into the kernel process request queue. Following kernel service call 108, kernel thread 104 returns to the user mode environment and continues execution.
Upon receipt of kernel service call 108, a kernel thread 107 which supports the requested functionality wakes from sleep, that is, a state of suspended execution, and moves the control block from the kernel process request queue to a pending I/O queue. In the case of an asynchronous read, kernel thread 107 then interfaces with a device driver routine to initiate an access to the disk hardware, as illustrated by arrow 112. Data read from the disk is stored within the global kernel address space. While waiting for the I/O request to complete, kernel thread 107 sleeps unless other I/O requests serviced by kernel thread 107 are received. Upon completion of the requested asynchronous read, kernel thread 107 is awakened by an interrupt from the disk interrupt handler, indicating that an asynchronous read has completed.
After kernel thread 107 wakes, kernel thread 107 determines which I/O request has been completed. Kernel thread 107 then copies the data from the kernel address space to the address space of user process 100. Because kernel thread 107 runs under a different process from the calling kernel thread 104, kernel thread 107 must obtain locks on a portion of the address space of user process 100 to ensure that the address space is not reallocated before the data transfer is complete. Once the data is copied into the user address space of user process 100, kernel thread 107 updates a status indicator within the control block of user process 100 to indicate that the requested data is available. In addition, if requested by user process 100, kernel process 106 transmits a signal to user process 100 to indicate that the requested data is available. Kernel process 106 then returns to sleep. After receiving notification of the availability of the requested data from kernel process 106 or by checking the status indicator within its control block, kernel thread 104 can then utilize the accessed data in its stream of execution.
Although the programming model illustrated conceptually in FIG. 4 provides enhanced performance over prior programming models which did not support multithreaded processes, the programming model depicted in FIG. 4 does not promote accountability for the use of system services by user processes 100. In other words, each user process 100 can consume system resources available through kernel processes 106 without regard to the priority of user process 100 since kernel processes 106 provide generic response to kernel service calls issued by kernel threads 104. Because of the generic support provided by kernel processes 106, kernel service calls issued by a high priority kernel thread 104 running under a user process 100 can be delayed in favor of a call issued by a lower priority kernel thread 104. In addition, when kernel threads running under multiple user processes 100 request a particular system resource accessible only through a single kernel process 106, the programming model illustrated in FIG. 4 requires that all of the kernel service calls be placed within a single kernel process request queue. Furthermore, it is often desirable that kernel threads 107 which access system resources in kernel mode retain the attributes of the calling kernel thread 104. The programming model depicted in FIG. 4, however, does not enable kernel threads 107 running under kernel processes 106 to inherit the attributes of calling kernel threads 104 running under a user processes 104.
Consequently, it would be desirable to provide an improved method and system for accessing system resources within a multitasking data processing system.
It is therefore one object of the present invention to provide an improved method and system for data processing.
It is another object of the present invention to provide an improved method and system for accessing system resources within a multitasking data processing system.
It is yet another object of the present invention to provide an improved method and system for accessing system resources within a multitasking data processing system which implements a multithreaded operating system kernel that supports kernel-only threads within user processes.
The foregoing objects are achieved as is now described. A method and system are disclosed for managing access to system resources by a user process within a multitasking data processing system. The data processing system includes a processor for executing kernel threads scheduled to the processor and a memory having a user address space which stores an application program and a kernel address space which stores an operating system kernel. The operating system kernel includes a kernel process comprising one or more first kernel threads which can each access the system resources. The user address space also stores a user process which has ownership of the system resources. The user process includes a second kernel thread comprising instructions within the application program. To access certain system resources, the second kernel thread invokes a first kernel thread within the user process. A thread scheduler schedules selected ones of the one or more first kernel threads and the second kernel thread to the processor for execution, such that access to the system resources by the user process is accomplished by invoking a kernel thread within the user process without invoking a kernel thread within the kernel process.
The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.